In lieu of swap: Analyzing compressed RAM in Mac OS X and Linux

The forensics community is increasingly embracing the use of memory analysis to enhance traditional storage-based forensics techniques, because memory analysis yields a wealth of information not available on non-volatile storage. Memory analysis involves capture of a system's physical memory so that the live state of a system can be investigated, including executing and terminated processes, application data, network connections, and more. One aspect of memory analysis that remains elusive is investigation of the system's swap file, which is a backing store for the operating system's virtual memory system. Swap files are a potentially interesting source of forensic evidence, but traditionally, most swap file analysis has consisted of string searches and scans for small binary structures, which may in some cases be revelatory, but are also fraught with provenance issues. Unfortunately, more sophisticated swap file analysis is complicated by the difficulty of capturing mutually consistent memory dumps and swap files, the increasing use of swap file encryption, and other issues. Fortunately, compressed RAM facilities, such as those in Mac OS X Mavericks and recent versions of the Linux kernel, attempt to reduce or eliminate swapping to disk through compression. The storage of compressed pages in RAM both increases performance and offers an opportunity to gather digital evidence which in the past would have been swapped out. This paper discusses the difficulty of analyzing swap files in more detail, the compressed RAM facilities in Mac OS X and Linux, and our new tools for analysis of compressed RAM. These tools are integrated into the open-source Volatility framework. © 2014 Digital Forensics Research Workshop. Published by Elsevier Ltd. All rights reserved. Introduction including information about currently executing processes, Traditionally, digital forensics has focused primarily on non-volatile storage devices and involved preservation, imaging, recovery, and analysis of files stored on hard drives, removable media, etc. That investigative model typically embraced a “pull the plug and image” strategy, which involved powering down forensic targets without regard for their live state andmaking copies of non-volatile storage devices for analysis. This resulted in loss of a significant amount of potentially actionable digital evidence, rd), [email protected] hop. Published by Elsevier L live network connections, data in the clipboard, volatile malware, and other OS and application data structures. Increasingly, the forensics community has become aware of the potential for live forensics and memory analysis to enhance the investigative process, yielding evidence not available on non-volatile storage. Live forensics typically involves a survey of a running machine “on-the-spot”, using a set of statically compiled binaries which are executed on the target to glean information about its state and available evidence. These tools are often traditional systems administration tools, which list running processes, monitor filesystem activity, capture network traffic, monitor changes to the Windows registry, and attempt to td. All rights reserved. Fig. 1. Image file and HTML fragment carved from a Windows swap file. These are deleted documents “trapped” in the un-sanitized space allocated by Windows to the swap file. G.G. Richard III, A. Case / Digital Investigation 11 (2014) S3eS12 S4 detect malware, such as keystroke loggers. Memory analysis typically involves capture of a system's physical memory (e.g., a RAM dump, acquired via a combination of software and/or hardware) for later investigation, offline, using memory analysis tools. Live forensics and memory analysis are similar in that they both potentially offer a wealth of data to a forensic investigator that would be otherwise unavailable. Similarly, they are both potentially invasive, disturbing the state of a running system to varying degrees, but memory analysis strives to minimize this disruption by requiring only that amemory dumping utility be executed on the system, rather than a number of evidence-gathering applications. Because of recent research advances in memory analysis, much of the live system state observable with live forensics can now be recreated in the lab from a physical memory dump. One aspect of memory analysis that remains elusive is investigation of the system's swap file, which is a backing store for the operating system's virtual memory system. Virtual memory is discussed in greater detail in Section Memory analysis for modern virtual memory systems, but briefly, the swap file is typically stored on disk and contains the contents of physical memory pages that have been swapped out due to highmemory pressure, essentially, a shortage of RAM induced by running large numbers of or particularly memory-hungry applications. The swap file can therefore contain actionable evidence, but because the swap file can be large and is stored on slow, non-volatile media, capturing a mutually consistent copy of both RAM and the swap file while a system continues to execute is very challenging.1 There are additional challenges in swap file analysis, which are discussed in detail in Section Swap files as a source of evidence, but a new virtual memory component emerging in modern operating systems, called compressed RAM or compressed swap, offers an opportunity to gather digital evidence which in the past would have been swapped to disk. After providing some additional background in the following sections on virtual memory systems and memory analysis, we discuss our newly developed plugins for the Volatility framework, which automatically identify and decompress compressed memory regions in both Mac OS X Mavericks and Linux, making this data available for analysis. We also discuss the results of a series of experiments, which offer insight into the quantity and quality of the additional evidence made available by our plugins. Memory analysis for modern virtual memory systems Virtual memory is an essential component of modern operating systems, providing a linear address space for processes and significantly simplifying memory management. Operating systems often include a paging mechanism in the virtual memory system, to allow the total size of the allocated memory regions of executing processes to exceed the size of physical RAM, by overflowing RAM into a swap file. Primitive versions of paging have existed since 1 However, in virtualized environments, a virtual machine snapshot can be generated, which may reduce the level of inconsistency. the Atlas system in the 1960s (Morris et al., 1967). In this paper, we focus on operating systems that fully support paging, although some operating systems, particularly those for mobile or embedded devices, do support virtual memory but either do not support paging at all (e.g., QNX) or support paging but without a swap file, bringing in readonly pages as necessary from files on non-volatile storage (e.g., iOS). On modern hardware, virtual memory is implemented using a combination of hardware and software, with most modern CPUs providing hardware support for virtual to physical address translation and tracking whether pages are resident in RAM. Access to non-resident pages results in a page fault, which is handled by the operating system, triggering one of a number of possible actions, including allocation or the page being swapped in. Swapping must be minimized to avoid thrashing (Denning, 1968a), where pages are continuously moved to and from the swap file because of a critical shortage of RAM, and the resultant impact on performance. Part of the reason that excessive swapping has such a serious impact on performance is the disparity between disk bandwidth and memory bandwidth, which differ by orders of magnitude. To illustrate this disparity, consider the memory bandwidth of the highperformance Mac Pro, introduced by Apple in 2013, which peaks at 60 GB/s. This model also sports some of the fastest flash storage to date, but storage bandwidth still peaks at 1.2 GB/s. To maximize performance, modern operating systems employ sophisticated G.G. Richard III, A. Case / Digital Investigation 11 (2014) S3eS12 S5 page replacement algorithms that strive to retain the pages that comprise the working sets (Denning, 1968b) for active processes, i.e., the pages that are in active use, in RAM, but some swapping is still inevitable when memory pressure increases. Swap files are discussed in more detail in the following section. Listing 1. Definition of the swap_crypt_ctx_initialize() function in the Mac OS X kernel, which creates new encryption keys for the encrypted swap facility on the first page-out after a reboot. 3 To our knowledge, Harlan Carvey coined the term smearing (Carvey, Swap files as a source of evidence Swap files are a potentially interesting source of forensic evidence, but traditionally, most swap file analysis has consisted of searches for strings or small binary structures. Searches of this kind target web page fragments, passwords, credit card numbers, IP addresses (Garfinkel, 2013), etc. In many cases, matches in themselves are revelatory, but it is virtually impossible to establish the provenance of data in the swap file without analyzing operating systems kernel structures in the virtual memory system. First, the swap file is organized as an unordered collection of raw memory pages (or segments, which may exceed a page in size), and discerning even which process generated the data in the swap file independently of the kernel structures can't be done in a reliable way. Second, unless specific measures are taken, such as setting a registry key in Microsoft Windows,2 the swap file is often not cleared when a system reboots, which leaves stale information in the swap file. This means that memory pages swapped out across (many) reboots may persist, all interleaved in the swap file. Third, and perhaps most importantly, some operating systems, such as Microsoft Windows, don't sanitize disk blocks when they are initially allocated to the swap file, meaning that data completely unassociated with virtual memory can be present in the swap file. An example of this is illustrated in Fig. 1, where file carving using Scalpel (Richard and Roussev, 2005) against a Windows swap file recovers an HTML file fragment and JPEG image “trapped” in the swap file, but unrelated to swapping activity. An additional complication is the increasing use of encrypted swap files, to minimize the leakage of volatile, private information onto non-volatile storage. For example, in Mac OS X 10.7 and later, swap files are encrypted by default, regardless of whether File Vault 2 whole disk encryption is activated. Furthermore, the 128-bit AES keys for encrypting the swap files are distinct from those used for disk encryption, and are regenerated automatically every time the system boots. Consider the function swap_crypt_ctx_initialize (osfmk/vm/vm_pageout.c) in the Mac OS X Mavericks kernel (Apple, 2013), illustrated in Listing 1. This function is executed on the first page out operation after Mavericks is booted, ensuring that all pages swapped out during the current session will be encrypted using a new key. Support for encrypted swap is also available in Windows (for Vista and later), and in Linux, via the dm-crypt facility, although neither enables encrypted swap by default. 2 For example, setting the ClearPageFileAtShutdown key in the registry instructs Windows to clear the swap file on shutdown, aimed at increasing security at the expense of performance. Assuming that a dump of physical memory and a copy of the swap file are available, memory analysis can theoretically be used to associate swapped out pages in the virtual address spaces of processes with the owning processes and to deal with encrypted pages (by retrieving the keys from RAM). In practice, this doesn't work well, because of memory smearing3duringcapture,where thestateof theprocesspage tables and kernel structures governing virtual memory are inconsistent with the state of the swap file. This occurs because, except in virtualized environments where a virtual machine snapshot or virtualmachine introspection (Javaid et al., 2012) can be used to more consistently capture or introspect both RAM and the swap file, it is generally very difficult in a running system to gather both in a consistent fashion (Kornblum, March 2007; Petroni et al., 2006). To see why, consider thatwhilecaptureof the swapfile is takingplace, the system continues to execute, and mappings between pages, their owners, and locations in the swap file may change, resulting in significant inconsistency. If the recommended process of acquiring memory first is taken, then the analyst will acquire memory using hardware or software, and then use other software to acquire the swap file. On systems with moderate to large amounts of RAM, the initial memory acquisition can take several minutes. During this time the system is still executing programs and changing swap information. By the time both memory is sampled and the swap file is acquired from disk, it is very likely (and has been observedby the authors) that thekernel swapdata structures will point to pages that have since been overwritten. If the acquisition tool blindly trusts this data then it will read data not actually associated with the translated virtual address. For example, it can mean a swapped-out mapping inside of Internet Explorer (under Windows) points to a swap file offset on disk that is actually now information from another 2005), referring to inconsistencies in a physical memory dump as a result of the system continuing to execute during capture. In our view, the term is also descriptive of the potentially graver inconsistencies that occur between physical memory and the swap file when simultaneous capture